Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/mint/mgr/sparcmgr/demo2.zoo/demo/ex/TODO/text0001.txt

Text File | 1984-06-11 | 31.5 KB | 619 lines

Here's Mark Horton's reply to my letter on bugs

>From [e-mail] Thu Jul 28 14:38:55 1983

Sorry this has taken so long, but your note was too long to digest
in the cracks between the other stuff I do.  Anyway, you've clearly
put a great deal of thought into this, and I appreciate your input.
I'll reply individually to your thoughts, and keep them on file
for use (someday) when vi gets rewritten.  Some of them are just
plain bugs that ought to be fixed soon anyway.

    PROBLEMS WITH COUNTS

         The most gross case of misbehavior is that of N^B!
    The effect is to redraw the screen 23N-44 lines further advanced.
    (Probably the numbers depend on the screen-size of the terminal;
    this is on a Z19, using termcap h19u.)  When N=1, this does indeed
    move you a screenful backward, but for higher N it moves the window
    forward some amount!  Further, whatever controls are supposed to
    monitor whether the command would land one at an acceptable line-
    number seem to have a different idea of what it is doing:  If you
    aren't already familiar with these weird effects, try setting the
    cursor near the end of a file that is more than 4 screenfuls long,
    and hitting 3^B.  (You might then try an insert at the place you get
    to, and a :f^] .)
This is a known bug, and was fixed in 3.8.  The count is supposed to subtract
(LINES-1)*N from the line number, but there's + that should be a -, so it
goes forward instead.  The check is correct, so it's possible to go off
the end of the buffer.
         N/pattern/ would be useful, but is not allowed.
N/pattern/ resets the window size (silly but true) to N.
         ND would be a natural synonym for dN$, by analogy with NC for cN$,
    but it doesn't work that way; it just ignores the N.
         Finally, if N is precisely the number of lines
    from the current line to the end of the file,  N$  will still correctly
    carry one to the last character of the file, but cN$, NC, dN$ and yN$
    refuse to do anything!  (NY does work, not being a synonym for yN$.)
    The failure of NC is particularly annoying; often when I am composing
    something, I go back to somewhere in the middle of the next-to-
    last line, say, and want to rewrite the rest of the sentence;
    2cc would kill not only the part I want to rewrite but also the OK
    beginning of the line, and 2C or 2c$ won't work.  I realize that I
    could get around this by keeping an empty line at the end of the file,
    but that should not be necessary.
While you're making valid observations here, are you aware that you can delete
the current sentence with d} ?  I think that's what you really want.


    PROBLEMS REGARDING SOURCE, MACROS, MAPPINGS
         These are enormously useful, but seem to have all kinds of hidden
    restrictions.

         The Appendix to the Ex Reference Manual, "List of Changes from
    Version 3.5 to Version 3.6" says ``A bug which prevented the source
    command from working...from visual has been fixed''.  It is true that
    one can now use  :so  from vi, but it still has a bug:  When
    the scriptfile invoked contains a global command
    and some other command(s) after it, everything after the first global
    command is ignored.  The same appears to be true of scripts in named
    buffers invoked from vi-bottom-line by  @x.
Sounds like a bug.

         (It is, perhaps, unexpected that one can invoke scripts with
    multiline commands using @x from vi's bottom-line at all, since such
    commands will not work if typed on vi's bottom line directly.
    A script like
        s/$/a\
        b
    invoked as @x will indeed work.  But strangely, if one tries to
    invoke from the regular mode of vi the script
        :s/$/a\
        b
    by putting it in buffer x and doing  @x, only the first line
    will take effect.)
In 3.7 (or 3.8, I'm not sure), you can say
    :s/$/a^V^Mb
to get a newline on the RHS.  Of course, this doesn't mean there isn't
a bug in scripts.

         Another serious restriction is that the command ``vi'' appears to
    be ignored in sourced ex-scripts, and though the command Q in macros of
    various flavors in vi (mapped characters, map!ed characters that contain
    ``...^V^[...Q...'';  @x scripts) does take one into ex, any ex
    commands after it are ignored.
The internals of getting a character from the tty are completely different
in ex and vi.  Pushing input for one doesn't affect the other.  So there
isn't much hope of changing this situation.

         I assume you are aware of whatever restrictions lead to the
    error-message ``Cannot yank inside global/macro'', since you must
    have written it, though ``inside'' seems to here have the peculiar
    meaning ``after a text-changing operation of the macro.''
         The error-message ``Can't undo in global commands'' is more
    mysterious, since I get it when I have a global command after
    a text-changing command in an @x script (though not in a sourced file).
         Anyway, the fewer such restrictions these operations were subject
    to, the more useful they would be!
It's the way undo is done - the text for undo is saved in the "last deleted"
buffer, and yank puts text there too.  Couple this with the fact that globals
and macros can be undone as a unit (they save their state before the first change)
and you'll see that the two notions can't coexist.  Of course, you can always
yank into a named buffer, even inside a macro.

         Although nested source commands are allowed (and I find them
    useful), they leave the editor in a ``noprompt'' state.  This
    can be gotten around by including ``se prompt'' as a line in the
    outermost scriptfile, but I would hope the problem causing it could
    be cured.
Bug, I guess.

         When one tries to ``:unmap!'' a ``:map!'' command whose
    right-hand-side begins with ^H (entered as ^V^H, of course), one
    gets the message ``That macro wasn't mapped''.  (One can get around
    this by using :unmap! ^V[character].)
Bug, I guess.

         Certain termcaps apparently produce automatic mappings, which
    unfortunately may interfere with useful vi commands.  In particular,
    on a tvi, ^L gets mapped to a movement command, which makes it
    unavailable for redrawing the screen, unless unmapped.
Well, there's no way for vi to tell the difference between ^L that the
user typed as ^L and ^L that the user typed as right arrow.  However, there
are a number of terminals that are upward compatible with the adm3a and use
^L for right arrow.  Vi has a special case for these built in - if the
terminal has insert/delete line, and ^L is right arrow, then ^R will redraw
the screen.


    PROBLEMS WITH DIAGNOSTICS

    "Hit return to continue" -- It took me a long time to realize that
    when I got this diagnostic there was an alternative to hitting
    return.  I suggest it be reworded
        "Hit Return or :"
    However, the behavior of the editor when this diagnostic is given
    seems to be inconsistent.  In particular, when the last of a serious
    of commands is
        :e otherfile
    and I get "Hit return to continue", then hitting : usually
    has no different effect from hitting return (or any other
    key), namely the screen is redrawn; yet I think that sometimes
    in this situation it has brought me directly to the bottom line
    as desired.  Very confusing.
         Would it be possible to have other alternatives than : and return
    available, such as /pattern ?  Or, more simply, when one would presently
    be given the diagnostic "Hit return to continue", why not just put the
    editor into the state it would have if one then hit :, since one would
    then still have the option of hitting return and getting into vi
    proper, but it would not require the extra keystroke : to
    begin a bottom-line command, nor would one go through the frequent
    frustrating experience of absentmindedly starting to write a
    bottom-line command, or a pattern-search, and then having to wait
    while the screen was redrawn because one had hit a key other than :.
There is an internal difference between "ex mode" (where it doesn't keep a
screen image) and "vi mode" (where it does).  Any : command that outputs more
than 1 line puts you into "ex mode", requiring "hit return to continue"
before clearing the screen and redrawing it with known stuff.  There is no
hope of this changing - the code is too spaghetti-ized already.  In the worst
case, the ! command scribbles on the screen and there's nothing vi can do
to know what the command did.

What you really want is for vi to check for typeahead and avert the refresh
when it's going to have to redo it anyway.  My curses does this, but I simply
don't have time to rewrite vi to use it.  This would also solve the other
problem you mention where macros ought to redraw the screen only once.
If you saw the insides of the code, you'd see it needs a rewrite to do this.
Each command knows the screen things to do to fix the screen.

What most of us do is hit DEL when the screen is being drawn with something
we don't want to see.  This aborts the update and leaves junk on the screen.
Then you move the cursor where you want it, and if the screen is still
garbaged, hit ^L.  Ugly but effective.

    "Using open mode"
    Again, it took me a long time to learn that when I tried to enter
    vi and got this diagnostic, it meant that the system had somehow
    lost the termcap for the terminal I was on, and that I would have
    to do something to get the correct termcap into the environment.
    Till I realized this, I generally ended up either struggling along
    frustrated in open mode, or logging out and logging back in.  I suggest
    that when someone calls for vi and the termcap is not appropriate,
    the editor should not be invoked in any form, but instead, a message
    be given such as:
         ``Your environment does not show a termcap entry permitting
    the use of the visual editor.  If you are working on a terminal not
    supporting vi (in particular, a device with no addressable cursor),
    you may enter one of the other modes of the editor with the command
    "open filename" or "ex filename".  If you are working on a terminal
    that should support vi, your environment entries are incorrect and
    should be corrected.  They presently show:
         TERM=....
         TERMCAP=....
    If you know the correct name or abbreviation for your terminal-
    type, type it at the end of the next line; if not hit return:
         % setenv TERM ''
         If the user typed an acceptable terminal-name, the message would
    continue, telling how to get the appropriate termcap.  If the user
    instead typed return, the message would ask him or her to type the
    name of the manufacturer shown on the terminal, not
    worrying about upper/lower-case distinctions, and a list of possible
    terminal names and abbreviations would be given... .  This whole
    program would not be part of the editor, so there would
    be no problem of space within the existing crowded confines of
    the editor code.
This, of course, doesn't belong in vi, but in login or tset.  In fact,
tset is much friendlier these days.  Vi will print a better diagnostic
if it knows you're on a "generic" terminal type such as "dialup" - in
terminfo there's a capability to indicate this, so it can print
    I don't know what kind of terminal you have - all I have is "patchboard"
3.7 can't do this because it can't tell the difference between a generic
terminal and a hardcopy terminal.

    "No such file or directory" -- I think there should be a distinction
    between these two cases, because of the important distinction in the
    consequences when the user tries to quit the editor:
The kernel doesn't distinguish, so it's hard for vi to.  This is just a perror
string.
    If the directory exists, the file is created, but
    if not, the results are more complicated -- I seem to recall on one
    occasion simply losing what I had written on my second try
    at quitting; though I just now did an experiment and this time
    repeated ZZ's and :x's simply gave repeated error messages.
Well, if it can't be reproduced, it doesn't stand much chance of getting fixed.
(Not that it would if you could reproduce it, of course.)

    "File already exists..." -- The ``List of changes from 3.5 to 3.6'' says
    ``If you get I/O errors, the file is considered "not edited"... .''
    I presume that this correction is somehow the cause of the fact that
    I frequently get the above message when trying to leave the editor
    on a machine with version 3.7, and have to use
          :w! %|q
Ick!  Most of us just type
    :wq!
which is equivalent and much shorter.
    to exit.  But I've never seen any evidence that there were I/O errors;
    it mainly seems to happen when I've written some lines to another
    file in the process of editing.  So the criteria the editor is using
    to decide when there have been ``I/O errors'' should be rechecked.
Actually, if you get ANY error (e.g. :foo<cr>) it resets the "buffer modified"
condition.  I have finally been convinced this is not right.  For a while, I
considered it a necessary evil in case your /tmp/Ex* file got an I/O error.

    "no such command from open/visual" -- This confused me in my first
    few days of using the editor, when I didn't understand that one
    couldn't use i and a (in either their vi or ex senses) from the bottom
    line of vi.  A message "i -- no such command from open/visual"
    was perplexing because I knew that "i" was indeed a vi command.
    Perhaps it should say  "no such command from open/visual bottom line".
OK.

    MISCELLANEOUS PROBLEMS

         In ex search and replacement patterns, \\ is supposed to represent
    a real \-character, but something goes wrong when this occurs
    at the end of a global command.  E.g., though
         :s/^/\\
    works OK (in vi or ex), the variant
         :.g/^/s//\\
    definitely does not.  In vi it turns everything off, in ex it seems to
    behave as though there were just a single \, and in a scriptfile,
    it -- does something still different, which you can discover if you
    don't know!
Backslash is special at the end of a line in global.  You need more \\'s.

    The Ex Reference Manual says, ``For sanity with use from within
    visual mode, ex ignores a ":" preceding any command.''  But it
    ignores it in the wrong place! -- not at the beginning of the
    command line, but just before the command letter itself.  I.e.,
    it accepts 1,3:s/^/     /, but not :1,3s/^/    /.
Hmm.

    SUGGESTIONS FOR MINOR ADDED CAPABILITIES

       In a multiline substitute command with the "c" option, when
    each line is displayed one has three choices: y, n or break.  There
    are some further options that would be useful.  One would be "p" --
    at present, "p" can only be included on the command line, which
    means that one has a choice between seeing the result of every
    substitution or none.  In practice, one would generally like to see
    the results of the first few cases to make sure that the command one has
    written does what one meant it to, and maybe a few tricky cases that
    come up; but not every case!   Another might be "u" -- to undo the last
    case for which one gave a "y".  Still another might be an option that
    would mean ``undo the "c" option -- I see that the substitute command
    is doing what I wanted, go ahead and finish it without me.''
If I were going to do something this involved (I didn't know anybody used the
c option anymore - most people use "n" and "." in vi) I would do query-replace
ala EMACS right.
        In a command  g/pattern/p,  the pattern in question is occasionally
    such that it takes a while to figure out where on the line it occurs.
    For this purpose, an option that ``pointed out'' the instance of the
    pattern, in the same manner that the pattern to be replaced is pointed
    out in substitute command with option c, would be desirable.
        When  g/pattern/p  gives more than a screenful of lines, it would
    be nice to have it piped through the equivalent of ``more''.
Nice but unlikely.  Unless, of course, you have page mode in your tty driver,
like we do, in which case you get it for free.

        ex has the command line option "-", which ``is useful in processing
    editor scripts''.  But if one wants to use a script in the course of
    an otherwise interactive editing session, it would be desirable to have
    a corresponding resettable option ``:se -'' (or ``:se nofb'').
Seems like a good idea.

         In strings in pattern-searches, it would be useful to have
    ^ and $ retain their ``magic'', so that /x[a$]/ could
    search for all occurrences of  x  before an  a  or a newline.
    (Of course, one would then have to decide whether  /x[^y]/ should
    include the case of  x  followed by a newline or not.)
This sounds pretty hard to do.

        Just as ex allows the command :vi, so I think that vi should
    have some bottom-line command equivalent to the regular-mode
    command  Q.  When one has done some text-changing bottom-line
    commands, and realizes one wants to go into ex, it can be time-
    consuming to hit return and then Q, and wait for the screen to be
    redrawn for vi before one gets the ex prompt.
This would be ugly, since the ex command routine would have to return an
indication to the vi routine to exit back to the top level ex command.
But I suppose it could be done.

         The option of putting several commands on one line, separated
    by, "|" is particularly useful in the vi bottom-line mode, because
    it avoids having the screen redrawn several times.  It would be
    useful to be able sometimes do the same thing with non-bottom-line
    commands, e.g. in editing a troff file at a low baud rate on a dumb
    terminal one might like to be able to do  i\fI^]3Ea\fR^]  without
    watching the line get redrawn twice.  Perhaps some key that would
    cause any sequence of commands to be ``held'' until some complementary
    key was hit would be useful.
         It would also be desirable to have a sequence of commands that had
    been given in this way available as one unit to be repeated by ``.'',
    if desired.
See above.  And get yourself a terminal with insert/delete char!

         The parenthesis-matching facility with % might be extended
    to match ` with ' and <  with  >.
OK.

         I will mention one facility that I discovered by surprize is
    possessed by  ed  but not  ex  --  sequences such as  \1  can be used
    within  ed  search-patterns.  E.g. (for the most trivial case)
         /\(.\)\1/
    will search for doubled letters.
This surprises me.


    DEBATABLE SUGGESTIONS
         I will mention here some possible changes which have the
    difficulty that they would change the meaning of existing commands,
    so that it could be argued that the disadvantage of users having
    to change their habits might outweigh the advantages.

         First, one might try to resolve, one way or another, the
    contradiction between the count arguments taken by the join commands
    in  vi and  ex:  In ex, jN joins N+1 lines; in vi, NJ joins N lines
    (except if N=1).
Yeah, ex should be N, not N+1.

         Second, the movement commands  tx  and  Tx  of vi (x any character)
    seem poorly defined.  Just as fx will ignore the character on which
    the cursor is presently sitting, even if it is an  x,  and move to the
    next occurrence, so I would think that  tx  should ignore the character
    immediately after the cursor, and  Tx  the character immediately before
    the cursor.  The point is that when one does  Nfx,  and finds that one
    had failed to count one occurrence of  x  and fallen short of where one
    wanted to go, one can hit  ;  and get there.  Likewise, on doing  Ntx
    and finding one has fallen short, one should be able to hit  ;  and get
    to the the next occurrence; but at present, hitting  ;  leaves
    the cursor in the same position; one must hit  ``2;''  to get any
    further.  In effect,  Ntx  is presently defined as  Nfxh;  I am
    suggesting that it be defined as  lNfxh.
Agreed.

         The sequences  cw, dw  and  yw  are presently violations of the
    principle that  c[movement],  d[movement]  and  y[movement]  change,
    delete, or yank everything from the current cursor position through
    the endpoint of the movement command.  cw does what one would expect of
    ce (in fact, they seem to be synonyms), while there is no way to get
    the effect which  cw  would have if it were treated ``consistently''.
    (E.g., if I have a line beginning  ``And if'', and I want to change it
    to ``If'', I cannot just put the cursor on the A and hit  cwI^].)  dw
    and  yw  delete up to the character immediately before the point to
    which ``w'' would take the cursor.  I would have to agree that this
    behavior of dw and  yw  is more useful than that which a literal
    interpretation of the movement rule would lead to; but perhaps it
    would become still more useful if when applied to the last word on
    a line, it deleted or yanked the space immediately before the word
    along with the word... .  On the other hand, one could argue for
    making a distinction between  cw  and  ce.
This is to make the user interface friendlier, and is a fact of life.
If I wanted to change "And if" to "If", I'd type "dw~".

         Though I see the motivation for the above definitions,
    I see no sensible reason why  Y  should be equivalent to  yy,  when
    C  and  D  are equivalent to  c$  and  d$.  I would vote for changing
    Y  to mean  y$.
The users wouldn't stand for such a change.  Too many are used to it like it is.
But you could always map it.

    RADICAL SUGGESTIONS

         Is there any reason for maintaining the distinction between
    the ``:'' state of vi, and  ex  itself?  At present, there are
    relative advantages that lead one to choose to go into one or the
    other for a given operation:  From the vi-: state, it is easier
    to return to the regular vi state; from ex, one has a more powerful
    range of commands; and it is easier to give a series of commands
    because each carriage-return gives one a new prompt.  My suggestion
    is that from vi, ``:'' should carry you directly to ex, and when you
    are in ex, carriage-return (^M) after a command should give you a new
    prompt, while ^] should put you into vi.  Conceivably, things might be
    simplified even further, and carriage return rather than : could
    be the key that would carry one from the regular mode of vi into ex:
The basic problem here is that if : put you into ex mode, you'd have to redraw
the screen when you hit return.  The motivation for : commands is that you
don't have to go through a conceptually hard mode change and wait for a
screen redraw.

                 .-------.    .-------.
        .-------. a,i... | basic |  ^M    |    |
        |  vi   |<------ |     |----->|  ex    |<---.
        | insert|     |   vi  |    |    |    |^M
        |  mode | ------>|     |<-----| mode     | ---'
        `-------'  ^]     |  mode |   ^]    |    |
                 `-------'    `-------'

    (Of course, ^M presently has a meaning in vi, but
    it has a synonym +.)  Clearly, there would also be no need for a
    special "Hit return to continue" state.
         I have not distinguished vi and open in the above diagram.
    My idea here is that ^] would actually return you to either vi
    or open, whichever you had last been in, and that to switch
    to the other, you could enter ex and type vi^] or o^] respectively.
    (Or you could type  vi^M, respectively o^M, and further ex commands,
    and the mode would be saved for the next time you hit a ^].)  Or
    alternatively, these could be made settable options: se visual
    respectively se novisual.
         Having gotten used to the editor as it now exists, I admit that
    I feel uneasy about the above idea -- the sense of knowing that
    I am ``still in vi'' when I hit :, and not that ``other land'' of ex,
    represents a kind of of orientation that it is disconcerting
    to abandon.  But I can't see any logical disadvantage in making
    such a change.  Can you?  Certainly, there would be things that
    would have to be thought out, such as what happens to bottom-line
    vi pattern-searches.  My thought would be that ``/'' from vi should
    give :/ (i.e., put one in ex at the start of a pattern-search),
    and ^] after a pattern-search should put one into vi at the appropriate
    character on the line, in contrast to ^M after a pattern search,
    which would leave one in ex at the appropriate line.  In general,
    I think such changes would lead to greater simplicity and learnability
    of the editor.
         I would also hope that excursions between vi and ex and back
    could be allowed in scriptfiles.  It might also be desirable for
    ex to have, in addition to a concept of ``current line'', one of
    ``current cursor position''... .

         Well, on to another subject.  One of the inconveniences I
    found very vexing when first learning to use the editor was that
    when in either vi insert mode, or ex/vi-bottom-line, it was very hard
    to edit what I was doing.  Within insert mode the only ``editing''
    I could do, without escaping, was with the three operations ^H,
    ^W and the kill character.  And on a slow line with a dumb terminal,
    escaping to make changes could be very time-consuming because large
    parts of the screen would insist on being redrawn.  Perhaps some
    other control-character could serve as
    a modified escape, that allowed one to edit what one had entered
    in the current insertion without having everything below it redrawn,
    and then return to it.  Obviously, if carried to its logical
    limit this idea could lead to ridiculous nests of
    editing operations; but there would be no need to carry it to its
    logical limit.
Why not just get a terminal with insert char?  You're paying in performance
for having an obsolete terminal.
         Anyway, the problem of editing ex-style commands
    was even worse, because there was no way to ``escape and
    revise''.  I eventually learned enough to realize that the solution
    was to edit complicated commands in another file and source it.
This is a standard complaint about a moded editor.  It couldn't be fixed
without taking away the property of ESC ending command lines.  Besides,
allowing editing on the bottom line would really break a lot of code.
    But it is sometimes very useful to have the text on which the
    commands are to act in front of you when composing them (e.g., you can
    yank and modify various pieces), which led to the variant of writing
    command lines within the file I was editing, and then writing
    those lines into another file and sourcing that, without ever leaving
    the current file.  But this is distracting to deal with
    when concentrating on the editing task itself, which led me
    to divise a scriptfile which would handle the writing-to-another-file-
    and-sourcing for me.  Or actually, several such files:  One for
    single-line commands to be used essentially once; one for single-line
    commands that I would want to use on the same file during various
    editing sessions, and so would want to keep available in that
    file, and one for multi-line commands (to be used once).  When
    I first got the idea, I thought one scriptfile would be enough, and
    I would call it ``do'', so that the command to execute a script I
    had written in a file I was editing would be ``:so do''.  The
    file it would write to and source would be ``do.again'', so that
    if I wanted to reuse it, I could ``:so do.again''.  When I realized
    the need for several versions, ``do'' became a directory.  Here,
    for your amusement, are the three files.  (Re the lines ``se prompt'',
    cf. my comment on that under PROBLEMS WITH SOURCE etc.):

      do/1  (for 1-time use of 1-line commands)
        .w! ~/do/again
        d
        so #
        se prompt

      do/1+  (like above, without deleting the command)
        .w! ~/do/again
        so #
        se prompt

      do/:  (to use this, write a multi-line command script, put : at
      the beginning of the first line, put the cursor on the last
      line of the script, and then source the following:)
        ?^:?s/:/
        ,''w! ~/do/again
        ,''d
        so #
        se prompt

    (I also created another version to use in case the script had
    to have an internal line beginning with ``:'', so that this couldn't
    unambiguously mark the beginning of the script.  This used
    a line which explicitly specified the address-range of the script.
    But I have never had a need for it, so I will not bother you with it.)
        Finally, having gotten an account on a machine with a version 3
    editor recently, I have divised still another way of doing this.  I
    have put in my EXINIT the command

        'map ^A "ayy:@a^M'

    and now, gratifyingly, the single stroke ^A has essentially the effect
    of ``:so do/1+''  -- except for the restrictions to which vi ``map''
    commands are subject.  But I've only been using this for a
    couple of weeks; so I have yet to learn how chafing those restrictions
    will or won't be.
         Anyway, it might be worth thinking about whether some of these
    things that I've done with macros should be incorporated in some form
    into the editor itself; or else whether these macros might be written
    up in the documentation (or some tutorials) on the editor.

         Next subject: Complicated pattern-searches in long files
    can be time-consuming.  I have seen the point mentioned
    that if a pattern-description can be begun with "^",
    this can speed up the search -- since the pattern-comparisons need
    only be begun at beginnings of lines.  In some cases, this might
    not be possible, but the user might be aware of some other
    character or character-sequence in the search-pattern
    that will occur relatively rarely in the file.  In such cases it would
    be desirable if the user could specify one spot from which the pattern
    search should start, working forward and backward from there, to
    minimize false starts.  E.g., if for some reason one wants to
    delete every word containing the letter m, the script
        %s/[^ ]*m[^ ]*//
    would become much less time-consuming if one could mark the point
    at which to begin, say writing
        %s/[^ ]*\!m[^ ]*//
    so as to instruct the editor to search for m's, and each time
    one was found, to find the longest possible strings of non-space
    characters before and after it, and delete these.   (This is a silly
    example, but I think the idea is clear.)
Isn't worth doing - this is fast enough for most people in most cases.

         Something that I've seriously felt the need for is the
    capability of searching for lines that satisfy more than one
    condition.  If one just wants to locate such lines, one can
    of course leave the editor and do a pipeline of two or
    more greps; but it would be nice to be able to perform global
    commands on such lines.
You want the PWB "or" operator.  This is hard to put in - their code
is really convoluted.

        Finally, any possibility of introducing the capability of searching
    for patterns including embedded newlines, a la sed?
Newlines aren't stored - the data structure is an array of lines.
So this is nearly impossible.
    Multiple windows, a la emacs?
Would be easy after a rewrite, but impossible with current code.
What you really want is a window manager, anyway, most of the time.

    ADDENDA
         I logged in this morning on an adm3a at 300 baud to go over this
    letter once more before sending it, and ran into another bug!  I had
    done 15^D to get a large scroll despite the low speed, and at one point
    I saw a line with a typo scrolling up.  So I noted its line-number, 402
    and without waiting for the screen to stop moving typed something like
    402Gfsrd.  What happened was that the change was made on line 407 rather
    than 402 -- presumably the cursor was sent to where 402 had been when
    the command was received... .
Knowing the internals of vi, I'd say this is impossible.  It probably just
screwed up your screen from line noise (or your terminal isn't truly full
duplex), or you got the wrong line number.
         Editing this letter this morning reminded me of another feature I
    have thought would be desirable for editing on dumb terminals at low
    speeds:  An option that would cause lines read from a file or typed
    in at the bottom of the screen to appear double spaced, with @ signs
    @
    between them, such as one gets when one deletes a line on such a
    @
    terminal.  (I have faked this effect here, though the fake will not be
    @
    very successful if you have  se nu  or  se list  on.)  The point is that
    @
    editing operations that presently cause painfully slow screen-redrawings
    would simply put material in in place of these fillers -- as happens
    now when one is lucky enough to be adding material just above a place
    where material was previously deleted.
Again, it would cost less to buy a real terminal.  You can get one for $500
or so now from Falco or Liberty or Zenith.

Thanks again for the input.

    Mark